Added project-specific Zed IDE settings #127793
Conversation
|
r? @nnethercote rustbot has assigned @nnethercote. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
|
I don't think this repo has a top-level |
This comment has been minimized.
This comment has been minimized.
I don't know much about IDEs, but @tgross35's suggestion about generating the Zed settings seems reasonable. |
|
As @tgross35 said, for this repo, |
|
OK, I'll examine |
|
@bjorn3 said:
Made |
|
This PR modifies If appropriate, please update |
rustbot
added
the
T-bootstrap
|
The job Click to see the possible cause of the failure (guessed by this bot) |
| @@ -0,0 +1,48 @@ | |||
| { | |||
| // The following commented-out VS Code settings are not supported by Zed yet. | |||
| // "git.detectSubmodulesLimit": 20 | |||
There was a problem hiding this comment.
This option was introduced for vscode in #120138. There is a fair chance that zed won't suffer from the same issue once it has a git ui anyway (they may not even add a hard limit on the amount of auto detected git submodules at all). I don't think there is any value in keeping this.
There was a problem hiding this comment.
It could be nicer to still keep one file for RA settings, then just delete this key via bootstrap (serde_json is already a dependency). So if there are future updates that work for both, they only need to happen in one file.
There was a problem hiding this comment.
In order to do this properly, I think we'll need three files: one shared file for rust-analyzer settings and one file each for the non-rust-analyzer IDE-specific settings.
Even IDE settings that do the same thing are different between the two IDEs. For example, to turn on format-on-save, VS Code wants "editor.formatOnSave": true, while Zed wants "format_on_save": "on",.
There are also JSON structure requirements that differ between the IDEs. For example, VS Code wants the rust-analyzer settings to use the standard dotted notation at the root of the JSON tree, like:
{
"rust-analyzer.rustc.source": "discover"
}Zed wants the rust-analyzer settings to live under a path through the JSON tree of "lsp", then "rust-analyzer", then "initialization_options", then the setting with the original dots signifying an increase in tree depth:
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"rustc": {
"source": "discover"
}
}
}
}
}So this means that we need to do JSON parsing of our three files, transformation of the structure, and JSON generation of the resulting .vscode/settings.json and .zed/settings.json files.
There was a problem hiding this comment.
You could also just have one rust source file with everything in json!, and build it dynamically
use serde_json::{json, Value};
fn base_settings() -> Value {
json! {{
// common settings
}}
}
fn vscode_settings() -> Value {
let vscode_specific = json! {{ anything new}}
let mut inner = base_settings();
inner.as_object_mut().unwrap().extend(vscode_specific);
json! {{
"lsp": {
"rust_analyzer": /* other nesting */ inner,
}
}}
}
fn zed_settings() -> Value {
// ...
}Which would also be kind of nice because it's easy to cover any config file schema or format. E.g. I would appreciate a Helix config at some point, but that uses toml (easy to convert from serde_json to toml, both are already dependencies of bootstrap).
But 🤷, that may be overkill.
|
|
||
| /// Create a `.zed/settings.json` file for rustc development, or just print it | ||
| /// If this method should be re-called, it returns `false`. | ||
| fn create_zed_settings_maybe(config: &Config) -> io::Result<bool> { |
There was a problem hiding this comment.
Can this function be deduplicated with the vscode version?
|
Should probably just see what bootstrap prefers here r? bootstrap |
tgross35
removed
the
T-compiler
|
Can Zed work with the VsCode configuration file somehow (like neovim)? FWIW #120611 would solve the whole problem of maintaining IDE specific files. |
| impl Step for Zed { | ||
| type Output = (); | ||
| const DEFAULT: bool = true; | ||
| fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { | ||
| run.alias("zed") | ||
| } | ||
| fn make_run(run: RunConfig<'_>) { | ||
| if run.builder.config.dry_run() { | ||
| return; | ||
| } | ||
| if let [cmd] = &run.paths[..] { | ||
| if cmd.assert_single_path().path.as_path().as_os_str() == "zed" { | ||
| run.builder.ensure(Zed); | ||
| } | ||
| } | ||
| } | ||
| fn run(self, builder: &Builder<'_>) -> Self::Output { | ||
| let config = &builder.config; | ||
| if config.dry_run() { | ||
| return; | ||
| } | ||
| while !t!(create_zed_settings_maybe(config)) {} | ||
| } | ||
| } |
There was a problem hiding this comment.
nit: This makes it more readable
| impl Step for Zed { | |
| type Output = (); | |
| const DEFAULT: bool = true; | |
| fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { | |
| run.alias("zed") | |
| } | |
| fn make_run(run: RunConfig<'_>) { | |
| if run.builder.config.dry_run() { | |
| return; | |
| } | |
| if let [cmd] = &run.paths[..] { | |
| if cmd.assert_single_path().path.as_path().as_os_str() == "zed" { | |
| run.builder.ensure(Zed); | |
| } | |
| } | |
| } | |
| fn run(self, builder: &Builder<'_>) -> Self::Output { | |
| let config = &builder.config; | |
| if config.dry_run() { | |
| return; | |
| } | |
| while !t!(create_zed_settings_maybe(config)) {} | |
| } | |
| } | |
| impl Step for Zed { | |
| type Output = (); | |
| const DEFAULT: bool = true; | |
| fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { | |
| run.alias("zed") | |
| } | |
| fn make_run(run: RunConfig<'_>) { | |
| if run.builder.config.dry_run() { | |
| return; | |
| } | |
| if let [cmd] = &run.paths[..] { | |
| if cmd.assert_single_path().path.as_path().as_os_str() == "zed" { | |
| run.builder.ensure(Zed); | |
| } | |
| } | |
| } | |
| fn run(self, builder: &Builder<'_>) -> Self::Output { | |
| let config = &builder.config; | |
| if config.dry_run() { | |
| return; | |
| } | |
| while !t!(create_zed_settings_maybe(config)) {} | |
| } | |
| } |
Seems like we will also need rust-lang/rust-analyzer#13529 for that. |
|
☔ The latest upstream changes (presumably #130091) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Okay well we added emacs and helix sample config files, so maybe just adding the zed file is fine here too :) #130932 |
This repository currently has project-specific VS Code IDE settings in
.vscodeandcompiler/rustc_codegen_cranelift/.vscode. Now there are equivalent project-specific Zed IDE settings alongside those.This fixes
rust-analyzernot being able to properly handle this project.Note that:
The contents of
src/tools/rust-analyzer/.vscodecould not be translated to Zed, as they aren't basic IDE settings.One of the VS Code settings in
.vscodehas no corresponding setting in Zed, and so this has been noted like this: